-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add retention period to deleted segment files and allow table level o… #8176
add retention period to deleted segment files and allow table level o… #8176
Conversation
9926115
to
c62d438
Compare
Codecov Report
@@ Coverage Diff @@
## master #8176 +/- ##
============================================
- Coverage 71.01% 63.84% -7.18%
+ Complexity 4314 4233 -81
============================================
Files 1624 1614 -10
Lines 84873 84681 -192
Branches 12791 12757 -34
============================================
- Hits 60273 54063 -6210
- Misses 20453 26673 +6220
+ Partials 4147 3945 -202
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
This PR is complicating things and trying to solve a problem that may never exist. It is fair to NOT expect that deletion of a table behave as per table config settings. it is ok to use the cluster behavior if the table config is not found. If it is desired that the segments be re-loaded onto another table, the operator should save the segments before creating a new table. Also, I don't understand the need to re-scan all segments when table config retention time is changed. |
...ntroller/src/main/java/org/apache/pinot/controller/helix/core/PinotHelixResourceManager.java
Outdated
Show resolved
Hide resolved
yes this requirement does exist. what we want to control is the "undo" period for a table after deletion.
Sorry let me re-clarify: the issue is that when the deletion retention period changes (whether cluster level or table level), does that retroactively apply to segments that has already been deleted. think of this sequence:
now question: does this apply to the segment that was deleted at
reloading on to another table is not the problem I was trying to address.
this was echo back to the example i said above: if we decided to retroactively apply the new retention period to previously deleted segments, we then need to read out all the DELETED_SEGMENTS, find their table-level override and the cluster level config. apply the retention deletion rule if they had already gone pass the new retention time. The approach this PR propose is, we DO NOT retroactively apply changes to already-deleted segments. e.g. we always apply the config at the time of deletion - by directly encoding the retention duration into the deleted segment filename. |
4537eec
to
f6243a2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM otherwise
...-controller/src/main/java/org/apache/pinot/controller/helix/core/SegmentDeletionManager.java
Outdated
Show resolved
Hide resolved
...-controller/src/main/java/org/apache/pinot/controller/helix/core/SegmentDeletionManager.java
Outdated
Show resolved
Hide resolved
...-controller/src/main/java/org/apache/pinot/controller/helix/core/SegmentDeletionManager.java
Outdated
Show resolved
Hide resolved
...-controller/src/main/java/org/apache/pinot/controller/helix/core/SegmentDeletionManager.java
Outdated
Show resolved
Hide resolved
...-controller/src/main/java/org/apache/pinot/controller/helix/core/SegmentDeletionManager.java
Outdated
Show resolved
Hide resolved
...-controller/src/main/java/org/apache/pinot/controller/helix/core/SegmentDeletionManager.java
Outdated
Show resolved
Hide resolved
...-controller/src/main/java/org/apache/pinot/controller/helix/core/SegmentDeletionManager.java
Outdated
Show resolved
Hide resolved
pinot-spi/src/main/java/org/apache/pinot/spi/utils/builder/TableConfigBuilder.java
Outdated
Show resolved
Hide resolved
pinot-spi/src/main/java/org/apache/pinot/spi/utils/builder/TableConfigBuilder.java
Outdated
Show resolved
Hide resolved
...pi/src/main/java/org/apache/pinot/spi/config/table/SegmentsValidationAndRetentionConfig.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will the file name encoded extension be there even if the table config does not have any override? Can we avoid that, please? So, cluster-level changes are applied immediately, but table level changes are honored at the time of deletion of the segment.
Also, for readability, you may wan to call one as "remove" and the other as "delete" (and define these in comments in SegmentDeletionManager and name the variables appropriately). Otherwise, it gets confusing.
Lastly, have you considered the possibility of file explosion? There will now be multiple copies of the same segment with different deletion dates. Is that desirable? Can it be used for DDOS?
...-controller/src/main/java/org/apache/pinot/controller/helix/core/SegmentDeletionManager.java
Outdated
Show resolved
Hide resolved
yes. actually this is a good idea. let me do that.
sound good. will do.
it won't be. once the segments are deleted they cannot be deleted once again. there's only one copied per deleted segment. |
715cb13
to
77f5e21
Compare
Echo on previous comments
this cannot be done unless controller is restarted as the retention time, so I decided to keep the time-to-delete suffix in all deleted segments. for other comments I've addressed. plz kindly take another look |
It is OK to reqiure a controller restart if a cluster level change is applied. In future (another PR) we can move this config to Helix, and a restart will not be required. Please apply this change. |
sounds good. done. will update pinot-docs accordingly once this rolls out |
…pplies immediately
93ba495
to
569206a
Compare
569206a
to
8433b3b
Compare
...-controller/src/main/java/org/apache/pinot/controller/helix/core/SegmentDeletionManager.java
Outdated
Show resolved
Hide resolved
...-controller/src/main/java/org/apache/pinot/controller/helix/core/SegmentDeletionManager.java
Outdated
Show resolved
Hide resolved
ac3fc2a
to
90499e1
Compare
90499e1
to
62e4ab5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's add a test for table config override, a test for no table config override, and ensure the file names are expected
...-controller/src/main/java/org/apache/pinot/controller/helix/core/SegmentDeletionManager.java
Outdated
Show resolved
Hide resolved
...-controller/src/main/java/org/apache/pinot/controller/helix/core/SegmentDeletionManager.java
Outdated
Show resolved
Hide resolved
...-controller/src/main/java/org/apache/pinot/controller/helix/core/SegmentDeletionManager.java
Show resolved
Hide resolved
...-controller/src/main/java/org/apache/pinot/controller/helix/core/SegmentDeletionManager.java
Outdated
Show resolved
Hide resolved
...er/src/test/java/org/apache/pinot/controller/helix/core/util/SegmentDeletionManagerTest.java
Outdated
Show resolved
Hide resolved
this is already added. but via mock(TableConfig.class) instead of a real table config object. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM otherwise
return lastModifiedTime + _defaultDeletedSegmentsRetentionMs; | ||
} | ||
|
||
private static Long getRetentionMsFromTableConfig(@Nullable TableConfig tableConfig) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(minor) Annotate the return as @Nullable
@@ -197,6 +200,15 @@ public Object answer(InvocationOnMock invocationOnMock) | |||
return null; | |||
} | |||
}).when(resourceManager).deleteSegments(anyString(), ArgumentMatchers.anyList()); | |||
|
|||
// fake segment lineage. | |||
SegmentLineage segmentLineage = new SegmentLineage(REALTIME_TABLE_NAME); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need to mock a segment lineage? Is this change related?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good catch not anymore since we fake the segment deletion manager. forgot to clean up
5ac97fa
to
dd04096
Compare
...-controller/src/main/java/org/apache/pinot/controller/helix/core/SegmentDeletionManager.java
Outdated
Show resolved
Hide resolved
…ix/core/SegmentDeletionManager.java Co-authored-by: Xiaotian (Jackie) Jiang <[email protected]>
apache#8176) Add support to control segment retention period on a per-table basis.
this is a follow up with several previous attempt to fix segment file deletion.
Goal
Add support to control segment retention period on a per-table basis.
Challenge
in previous Approaches - we previously attempt to add field in TableConfig that controls the retention period. this causes many corner case problems
Therefore it is semantically hard to do a post-deletion retention override.
New Approach
In this PR we avoid these issues entirely by employing one practice: segments retentions are set when they are being deleted based on the tableConfig override or the default cluster setting AT THE TIME OF DELETION. no retro editing of the override will be supported for any deleted segments.
This means if there's any new changes to the cluster level or table level override, they will only apply to newly deleted segments and will not affect any segments that are previously deleted.
See: #8078 and #8069 for more details.